Many of today's servers, such as web servers, mail servers, and database servers, to name a few, rely upon configuration information to determine their behavior at runtime. For example, a web server may consult a set of configuration information to determine the number of threads it should allocate at any particular time. As a further example, a web server may use configuration information to determine how a particular request should be processed (e.g. which functions or applications should be invoked). Configuration information may be used to dictate many different aspects of server operation, and the type of behavior that can be controlled using configuration information will differ from server to server. One of the main advantages of using configuration information to dictate the behavior of a server rather than hardcoding the behavior into the server code is that it enables an end user, such as a system administrator, to easily control the operation of the server. By simply modifying the configuration information, an end user can customize the behavior of the server to fit his/her needs. No changing or recompilation of any of the server code is necessary.
Typically, to enable a set of configuration information to be used at runtime, a server interprets and digests the configuration information at system start up time. More specifically, at start up time, a server process is instantiated, and that server process interprets and transforms the configuration information into a set of runtime configuration data structures that are convenient for the server process to access and manipulate. Once the configuration data structures are created, they are used by the server process during runtime to process all requests.
In some circumstances, it may be desirable to alter the configuration information after a server process has been instantiated and running. For example, based upon usage history, a system administrator may wish to adjust the number of threads that are allocated by the server to optimize server performance. To implement a change in configuration (i.e. to reconfigure the server), it is currently necessary to carry out at least two steps. First, the underlying configuration information is modified. This may be done, for example, by using an editor, such as a text editor. Once the configuration information is modified, the server is shut down and restarted. Upon startup, a new server process is instantiated, and that new process interprets the modified configuration information and transforms it into a new set of runtime configuration data structures. The new data structures are thereafter used by the new server process to process all requests.
As noted above, it is currently necessary to shut down and restart a server in order to implement a change in the server's configuration. In many implementations, this is not a viable option. First of all, in a complex server, it can take on the order of minutes to restart a server. In terms of request traffic, three minutes is an extremely long time, and a tremendous amount of traffic can be lost in that time. Many servers, such as those servicing commercial websites, cannot afford to have this amount of down time. Also, many companies guarantee twenty-four hour service, seven days a week. For a server in such a company, down time is not a viable alternative.
This down time problem is especially onerous in servers in which configuration information is updated on a fairly regular basis. An example of such a server is an internet service provider (ISP) server that hosts a large number of websites/domain names. As a new customer signs on for the service, the configuration information is updated to include the new domain name. As an existing customer cancels service, the configuration information is updated to remove the existing domain name. As customers change their service requirements, the configuration information is altered to reflect the change. For a server that supports a large number of websites, the configuration information may be updated on a fairly regular basis. If the server were shut down to implement each and every update, the amount of down time that would be incurred would be prohibitively large. Because of this, many servers are forced to implement updates to configuration information as a batch on an infrequent basis (e.g. once a day), which is not an optimal solution. As the above discussion shows, the current methodology for reconfiguring a server leaves much to be desired. Accordingly, an improved server reconfiguration mechanism is needed.